View figure.
This chapter describes how to use the Multilink PPP Protocol (MP). It includes the following sections:
The Multilink PPP Protocol allows you to increase the bandwidth of:
Increased bandwidth is accomplished by defining a virtual link made up of multiple links. The bandwidth of the resulting MP bundle is almost equal to the sum of the bandwidths of the individual links. The advantage is that large data packets transmitted across a single link can now be fragmented, transmitted across multiple links, and rebuilt at the receiving end station. MP uses both the Bandwidth Allocation Protocol and the Bandwidth Allocation Control Protocol to dynamically add and drop PPP dial circuits to a virtual link. MP also uses Bandwidth-On-Demand (BOD) to add "dedicated" MP dial links to an existing bundle.
There are two types of MP links: those that are dedicated and those that are simply enabled. A dedicated MP link is an MP-enabled interface configured as a link to a particular MP interface. If the link attempts to join another MP bundle, or if MP is not negotiated at all, the software terminates the link. All PPP links except for layer-2-tunneling interfaces can be configured as dedicated MP links. PPP leased links must be configured as dedicated MP links.
PPP dial-circuits and Layer 2-Tunneling can be configured as MP enabled. An MP-enabled link that is not dedicated can become a link in any MP bundle. If MP is not negotiated, the link operates as an independent interface using the link's configured protocols.
You can configure a Multilink PPP interface that consists of multiple PPP dial circuits as part of the MP bundle.
There are also two types of MP interfaces: those that have a dedicated link and those that do not. An MP interface needs a dedicated link in any one of the following situations:
MP interfaces that do not have a dedicated link must be inbound-only interfaces. These interfaces are similar to the any inbound dial circuit.
The Bandwidth Allocation Protocol (BAP) and its control protocol (BACP) allow an MP interface to increase and decrease its bandwidth by adding and dropping dial circuits. When the bandwidth utilization algorithm determines that a link should be added to the bundle, if there is an available PPP dial-circuit, and the peer agrees, an additional call is placed.
BAP first searches for any idle dedicated PPP dial circuits for the MP interface, and then for any MP-enabled PPP dial circuit. It will not, however, use a dedicated PPP dial circuit of another MP circuit. The configured maximum number of links on the MP interface will never be exceeded.
BOD uses configured dial-circuit phone numbers to place calls when needed to add dedicated MP dial links to an existing bundle. Links are added to the bundle one at a time, if needed, during a polling period. BOD adds any PPP serial links to the bundle first and will retain the serial links throughout the life of the bundle. BOD only drops dial links.
MP supports the following features:
However, WRS, Dial-on-Demand, and DIALs are only supported on MP bundles that contain only dial circuits.
When configuring an MP bundle, keep the following in mind:
Important:
An MP bundle with a Layer 2 Tunnel that contains a phone hunt group that spans multiple physical Network Access Servers is known as a multi-chassis MP. Multi-chassis MP uses rhelm or user-based tunneling (see "Using Local or Remote Authentication" in Using and Configuring Features) to establish the MP endpoint destination. See "Using Layer 2 Tunneling Protocol (L2TP)" in Using and Configuring Features for more information about L2TP.
Configuring an MP interface depends on the type of interface used in the MP bundle. The following sections contain examples of the various configurations.
After configuring the MP interface, you may configure bandwidth-on-demand (BOD). The following example configures BOD on existing MP interface 17:
Config> net 17 MP config: 17> enable bod Enable BAP? [N] MP config: 17> set bandwidth-on-demand parameters Add bandwidth % [90]: Drop bandwidth % [70]: Bandwidth test interval (sec) [15] MP config: 17>
This section shows how to configure a Multilink PPP interface by using an example that configures Multilink PPP with two ISDN dial circuits.
*t 6 Config>add dev dial-circuit Adding device as interface 7 Defaulting Data-link protocol to PPP Use "net 7" command to configure circuit parameters Config>add dev dial-circuit Adding device as interface 8 Defaulting Data-link protocol to PPP Use "net 8" command to configure circuit parameters Config>add dev multilink-ppp Enter the number of multilink PPP interfaces [1]? Adding device as interface 9 Defaulting Data-link protocol to PPP Use "net intf" command to configure circuit parameters Config>
Config>net 7 Circuit configuration Circuit config: 7>set dest out Circuit config: 7>set calls outbound Circuit config: 7>set net 6 Circuit config: 7>
Circuit config: 7>encapsulator
Point-to-Point user configuration
PPP 7 Config>enable mp
Enabled as a Multilink PPP Link,
Use as a dedicated Multilink PPP link? [No]: yes
Multilink PPP net for this Multilink PPP link [1]? 9
NOTE: PPP configuration will be obtained from the Multilink PPP
net. It is NOT necessary to configure PPP for this net!
| Note: | You cannot configure PPP parameters for dedicated links from this prompt. Dedicated links use the existing MP interface's PPP configuration. |
By answering "Yes" to the question "Use as a dedicated Multilink PPP link?" the link becomes dedicated to the specified Multilink PPP interface (9 in this example). In this case, the link must be used for an MP bundle and must join the specified MP interface. The link cannot be used as a regular PPP dial circuit.
Answering "No" to "Use as a dedicated Multilink PPP link?" will allow this PPP dial-circuit to join any MP interface. At least one PPP dial-circuit must be a dedicated link to an outbound MP interface.
A dedicated PPP dial circuit obtains all PPP parameters (LCP options, authentication, and others) from its MP interface. MP enabled PPP dial circuits joining the same MP bundle must negotiate the same LCP parameters and authentication name.
To configure MP on a PPP serial link, you enable MP on the interface using the net command. The link obtains its PPP configuration from the MP net.
Example:
Config> net 1
PPP 1 Config> enable MP
Multilink PPP net for this Multilink PPP link [1]? 8
NOTE: PPP configuration will be obtained from the Multilink PPP
net. It is NOT necessary to configure PPP for this net!
PPP 1 Config>
To configure MP on an L2TP net, you enable MP through the L2TP encapsulator. You then must configure the same PPP negotiation parameters (see "Configuring L2TP" in Using and Configuring Features) for information about all nets joining in a single bundle.
Example:
Config> feature layer-2-tunneling
Layer-2-Tunneling Config> encapsulator
PPP-L2TP Config> enable mp
NOTE: It IS necessary to configure PPP for this net! PPP
negotiation parameters must be configured the same for
all nets wishing to join the same Multilink PPP bundle.
PPP-L2TP Config>
To configure MP for Multi-Chassis MP, configure the DIALs feature for multi-chassis MP. The software prompts you for the endpoint discriminator to use.
Example:
Config> feature DIALs DIALs Config> set multi-chassis-mp Enter Endpoint Discriminator to use from stacked group (0 for box S/N): 2345 DIALs Config>
The following example shows multichassis MP when ports RTR-2 and RTR-3 are in a hunt group.
Figure 46. Multichassis MP
View figure.
Because there is a many-to-many relationship between access routers and MP-concentrators, all access routers (RTR-A, RTR-B) should be kept on a separate administrative domain from "MP concentrator" routers (RTR-Z). This applies if you want to use remote authentication (that is,RADIUS), you will need two RADIUS servers, one for access routers and one for MP concentrators. If you are using local-list, you are already using separate administrative domains.
In this scenario, you can choose to tunnel based on PPP username or "rhelm" name. It is less rigorous to use rhelm-based tunneling. The idea is to configure a tunnel-profile for RTR-Z on both RTR-A and RTR-B. No additional PPP users are required on these routers. RTR-Z would require 2 tunnel-profiles: one for RTR-A and one for RTR-B and a PPP username (in the form <username>@RTRZ) for each anticipated user. All dial-in circuits are configured on the "access" routers. The "MP concentrators" would have layer-2-tunneling devices and multilink-PPP devices.
At this point, we have "statically configured" multi-chassis MP. This means that a particular PPP username will always terminate MP on a preconfigured router as opposed to supporting an additional protocol which dynamically finds MP bundle heads and tunnels when needed. This network implementation will also help avoid client PPP negotiation idiosyncrasies when using different media types for each link in a bundle (for example, tunnel one link and not the other). For example, DIALs clients cannot renegotiate LCP at any point. Also, Microsoft DUN clients do not fully support LCP renegotiation.